The approaches described in this section could be pursued, but are not necessarily approaches that previously have been conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In an Internet Protocol (IP) multicast group, one group member host can multicast data packets over a computer network to multiple other group member hosts. Each of the other group member hosts receives data packets that have been multicasted to the group address. Data packets may be multicasted to a group according to a multicasting routing protocol such as Protocol Independent Multicast (PIM). PIM is described in the Internet Engineering Task Force (IETF) Request For Comments (RFC) 2362.
A host may join a group through a mechanism provided by an admission control protocol such as Internet Group Management Protocol (IGMP). IGMP is described in IETF RFC 1112. Once a host has joined a group as a group member, the host receives all messages that are multicasted to the group address. Unfortunately, current multicasting routing protocols and admission control protocols do not require that hosts are authorized prior to joining an IP multicast group. As a result, a rogue host can join a group unchallenged, multicast data packets to the group, and receive data packets that have been multicasted to the group.
To prevent rogue hosts from understanding confidential data that has been multicasted to a group, group members may encrypt data prior to multicasting the data to the group. Group members may encrypt data using a symmetric-key encryption algorithm such as that specified by Data Encryption Standard (DES). DES is described in Federal Information Processing Standards Publication (FIPS PUB) 44-2. Data encrypted with a symmetric-key encryption algorithm can only be decrypted with the same key that was used to encrypt the data.
Thus, even though a rogue host may intercept encrypted data that has been multicasted to a group, the rogue host cannot decrypt the encrypted data without the key, which is distributed only to legitimate group member hosts through secure means. Additionally, because rogue hosts lack the key, rogue hosts are unable to encrypt data using the key. Consequently, legitimate group member hosts can identify, as potentially being the forgery of a rogue host, data that has not been encrypted with the key.
Unfortunately, even in an environment in which such encryption is implemented, a rogue host still can perpetrate attacks on legitimate group member hosts by re-multicasting, or “replaying” legitimately encrypted data packets that the rogue host intercepted. Because the data packets are encrypted with the key, legitimate group member hosts are unable to determine that the data packets have been replayed. As a result, legitimate group members accept the replayed data packets as being legitimate and timely.
By replaying data packets, a rogue host can perpetrate attacks that may cause multiple adverse effects. By replaying data packets in massive amounts, a rogue host can overwhelm legitimate group member hosts so as to prevent most, if not all, legitimate data packets from being received by the legitimate group member hosts. Such an attack is called a “denial of service” attack. Furthermore, replayed data packets may contain time-dependent information, such as a stock quote, which is correct only for a relatively short interval of time. Legitimate group member hosts are oblivious to the untimeliness of the information, and, in their ignorance, may allow the “stale” information to be used by applications and/or users as though the information was “fresh,” with potentially disastrous results.
Various approaches could be used in an effort to protect against replayed data packets. According to one approach, a sender host adds a different sequence number to each data packet that the sender host will send. A data packet's sequence number indicates the data packet's proper order relative to other data packets sent by a particular host. While two or more different hosts may send different data packets that contain the same sequence number, no host adds the same sequence number to more than one data packet that the host will send. Therefore, if a recipient host receives a data packet that contains a sequence number that was contained in another data packet previously received from the same sender host, then the recipient host may presume that the data packet has been replayed.
Under this approach, a sequence number added to a data packet by a host has no relation to another sequence number added to another data packet by another host. Therefore, under this approach, each recipient host is required to maintain separate sequence number state information for each different sender host. In an environment characterized by a very large number of sender hosts, maintaining separate sequence number state information for each and every sender host can consume a prohibitive amount of storage space. This issue is acute when receivers are packet routers that have limited storage. From a practical standpoint, the sequence number approach is not scalable.
According to another approach, a timestamp is added to each data packet. The timestamp reflects the time of day at which the data packet was sent. By comparing the current time of day to the time of day indicated by the timestamp, a recipient host can determine whether a data packet containing the timestamp is fresh or stale.
However, if a recipient host's clock differs from the sender host's clock, the recipient host may determine, mistakenly, that a data packet is stale when, actually, the data packet is fresh, or that a data packet is fresh when, actually, the data packet is stale. Thus, to be effective, hosts in environments that rely upon timestamps to protect against packet replay are required to have tightly synchronized internal clocks. Network Time Protocol (NTP), described in IETF RFC 1305, may be used to synchronize the times of day of multiple hosts. Typically, absolute inter-host time synchronization involves significant communications overhead, which increases as the number of hosts increases. From a practical standpoint, the timestamp approach is not scalable.
Additionally, some of the most widely used data security protocols, such as IP Security Protocol (IPsec) Encapsulating Security Payload (ESP), do not provide a standard mechanism for the inclusion of a timestamp within a data packet. ESP is described in IETF RFC 2406. Adapting existing systems that currently use such data security protocols to cause data packets to contain timestamps in a standard format would be a potentially expensive and time-consuming task.
Based on the foregoing, there is a clear need for a method of verifying data timeliness in a multiple-sender environment without requiring recipients to maintain separate state information for each sender, without requiring senders and recipients to maintain tightly synchronized time, while also allowing hosts to continue to use existing data security protocols that do not provide a standard mechanism for adding timestamps to data packets.